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An Object-Oriented Minimization Package for HEP 
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A portion of the HEP community has perceived the need for a minimization package written in CH — h and taking 
advantage of the Object-Oriented nature of that langauge. To be acceptable for HEP, such a package must 
at least encompass all the capabilities of Minuit. Aside from the slight plus of not relying on outside Fortran 
compilation, the advantages that a CH — h package based on O-O design would confer over the multitude of 
available CH — h Minuit-wrappers include: Easier extensibility to different algorithms and forms opf constraints; 
and usage modes which would not be available in the global-common-based Minuit design. An example of 
the latter is a job persuing two ongoing minimization problems simultaneously. We discuss the design and 
implementation of such a package, which extends Minuit only in minor ways but which greatly diminishes the 
programming effort (if not the algorithm thought) needed to make more significant extensions. 
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1. MOTIVATION 

1.1. Minuit 

For many years, the gold standard in minimization 
packages used by High Energy Physicists has been the 
Fortran program Minuit This code contains algo- 
rithms which are well-suited for many HEP uses, espe- 
cially when there is a large data set and minimization 
is needed to find a multi-parameter fit. 

The principal algorithm, called migrad, is a vari- 
able metric method. This exploits the idea that al- 
thought a costly second derivative computation is 
needed to move to the function minimum, that ma- 
trix need not be computed accurately for early steps 
(since it will be changing significantly anyway). In- 
stead, it can be iteratively improved, so that by the 
time the method gets near the actual minimum, the 
matrix is accurate and rapid convergence occurs. 

Another prime capability is a set of routines for an- 
alyzing the solution: The HESSE method of supply- 
ing the parameter error correlation matrix, the MINOS 
method of nonparabolic chi-suqare error intervals, and 
CONTOUR, which depicts the shape of a fixed-sigma er- 
ror curve around the solution point for functions which 
may not be well-described as bi- linear forms. 

1.2. Is a New Minimization Package 
Needed? 

Minuit, however, is getting a bit stale. It is writ- 
ten in Fortran, which is no longer the lingua franca of 
computing in HEP; it can be awkward to link CH — h 
code with code from a different language. And modern 
users would like certain advantages relating to treating 
a minimization problem and its function, algorithms 
and domains, as objects. One such advantage is the 
option of performing multiple independant minimiza- 
tions in tandem. 

The Minuit code is difficult to maintain, as evi- 
denced by the fact that there have been no enhance- 
ments since a major overhaul done by F. James about 



a decade ago, and no major algorithm improvements 
for some time before that. The HEP community 
knows of promising alternative methods, such as FU- 
MILI 2] and the related LEAMAX Q, and certainly 
the field has advanced in these years, with simulated 
annealing and genetic algorithms maturing. The fact 
that nobody has seen fit to incorporate these as op- 
tions in Minuit can be taken as evidence that such 
changes would be hard to make. 

Even assuming that Minuit needs no maintenance 
because all bugs have been eliminated and that its ca- 
pabilities are forever adequate, what happens when all 
the CERNLIB Fortran modules start becoming awk- 
ward to bring forward? There is reason to fear that 
Minuit might fall into functional obsolecence. 

We asked a group of HEP physicists who work heav- 
ily with CH — h computation whether it would be a good 
idea to produce a CH — h object-oriented minimization 
package with Minuit's capabilities. About 40% re- 
acted positively: "it's about time we had this." Some 
of these physicists had faced a tougher time accom- 
plishing an actual project, for lack of a good stand- 
alone CH — h minimizer. 

Others reacted with some variant of "are you out of 
your mind? Sombody must already have done this!" 
We will argue below that nobody actually has deliv- 
ered an adequate object-oriented minimizer with the 
capabilities required. 



1.3. Other Minimizers 

Most commercial minimization packages fall short 
in capability aspects. In some cases, their algorthms 
are not as appropriate as MIGRAD for the sort of prob- 
lems which occur in HEP; more often they lack solu- 
tion analysis methods equivalent to CONTOUR and MI- 
NOS. Also, non-trivial licensing issues can hinder the 
adoption of commercial codes as de facto standards in 
the HEP community. 

A more promising approach is to translate Minuit 
directly into C or C++. Several analysis packages, 
including ROOT p|, provide fitting in this manner. 
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Another approach is to place a wrapper around the 
Minuit code, to allow the interface to be expressed in 
C++, and package the compiled Fortran code along 
with the wrapper as an integrated library. Gemini |5( 
does this, providing a shell over a choice of Minuit or 
the commercial NAG C minimizcr. 

Either approach solves the problem of inter- 
language awkwardness, but they do not address the is- 
sue of maintainability and ease of enhancement. And 
fundamentally, a minimization problem still cannot be 
treated as a first-class object. 

The Root team, in particular, has done significant 
work both in cleaning up the f2c translation of Mi- 
nuit and in removing deficiencies involving multiple 
minimizations. But not everybody welcomes the re- 
quirement of linking to the large body of Root code, 
when all that is needed is a minimizer. 

One other C++ object-oriented minimizer is defi- 
nitely worth mentioning. Matthias Winkler, mentored 
by Fred James at CERN, is working on an "object- 
oriented re-implementation of Minuit in CH — h" under 
the auspices of the SEAL programme. Clearly two 
nearly-identical good C++ minimizers are not needed. 
We have been in contact with Dr. James, and in- 
tend to coordinate the two parallel efforts, hoping to 
emerge with a single package of superior design and 
implementation quality. 

1.4. Minimizers vs. Fitters 

It is worth saying a few things about the concept 
of a minimizer as opposed to a fitter. Since most ap- 
plications of minimization in HEP are motivated by 
multi-parameter fits to data, the two can be confused. 

Most of the packages which wrap Minuit tend to 
be fitters, that is, they present a convenient way to 
provide a function form and a data set, and go about 
using minimization to optimize the parameters in a 
fit to that data. When the function / is a chi-squared 
sum, the resulting minimization procedure is special- 
ized, in the sense that the nature of the fitting problem 
assigns a meaning and a natural scale for differences 
in values of f(v). Algorithms (such as MIGRAD) which 
yield a meaningful estimated distance above the true 
minimum can exploit a natural termination condition, 
since the value of f(v) assumed to be accurate only to 
some small fraction of a unit in chi-squared. And anal- 
ysis of the estimated shape of f(v) can meaningfully 
be translated to statistical statements about correla- 
tions among the parameters. 

However, the kernel operation of minimizing an ar- 
bitrary function is a valid capability to ask for. By 
design, the CH — h minimization package under devel- 
opment is a minimizer, not a fitter. One can automate 
the steps to turn a fitting task into a minimization 
problem. Several others have done this in C++, and 
though it may become convenient to package such a 



fitter adaptor with the minimizer, this adaptor need 
not be considered part of the development of the min- 
imizer. 



2. PACKAGE REQUIREMENTS 

The requirements guiding the developement of this 
package are driven by the goal of acceptance and 
widespread use in the HEP community. This will re- 
quire providing a significant set of capabilities, dis- 
cussed below. The package must not to be deficient, 
with respect to Minuit, in any capability. Also, at- 
tention must be paid to certain performance consid- 
erations. The package must be clean to use and self- 
contained, and should not depend on other packages. 
And stringent testing will be required, to ensure that 
the package is robust. 

At the same time, we wish to provide interfaces 
which will encourage code which is clear and readable 
and which does not deviate from the classical C++ 
coding idioms accepted by top practitioners. 

Our goal is to provide a package that can be used 
for many years. It is impractical to provide something 
which is "so good it will never need to change." In- 
stead, we strive to organize and code the package such 
that enhancements and maintenance changes will be 
as easy to incorporate as possible. 

In order to stand the test of time, we feel the min- 
imization package must include complete and easily 
understood user documentation, as well as full math- 
ematical documentation of all algorithms used. 

2.1. Capabilities 

The key requirement is that every capability present 
in Minuit must be matched in our minimization pack- 
age. 

It could be that Minuit is the ideal minimizer for 
HEP per se. Or perhaps the way physicists have 
grown accustomed to doing data analysis has evolved 
in tandem with Minuit to take advantage of its capa- 
bilities. The point is moot-any package which cannot 
match the capabilities present in Minuit will be unac- 
ceptable to the HEP community. 

These capabilities lie in several areas. Clearly, 
the Minuit algorithms (MIGRAD, simplex, minimize) 
must be present. And user code must be able to 
control steps taken and selection of (and switching 
among) algorithms. Code must be the able to estab- 
lish limits on some or all of the function parameters, 
and fix and release their values. And the methods for 
error analysis, nonparabolic error intervals, and two- 
parameter contour lines (analogous to HESSE, minos, 
and contour) must be provided. 

It is tempting, along the way, to make any tweaks 
that arc noticed to be pure improvements. Some of 
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these arc pure extensions, such as the ability to de- 
fine parameters which have only an upper or lower 
limit. Others might be minor algorithm improve- 
ments, such as a theoretically superior finite difference 
step size when numerically computing derivatives. In 
such cases, it is required that default behavior pre- 
cisely mimic the procedures used by Minuit. 

The Minuit-matching requirement is a matter of ca- 
pability, and not of interface. Minuit assumes one of 
two usage paradigms: 

1 . The minimizcr is a static facility, which the user 
code explicitly initializes to embark on a prob- 
lem. The user program then controls this facility 
by calling various subroutines. 

2. A commanding minimizcr program is supplied 
with "cards," each directing an aspect of initial- 
ization or an element of control. 

Clearly, both of these paradigms are obsolete in the 
context of a C++, object-oriented package. The ex- 
perienced Minuit user may miss the mantra of call- 
ing mnexcm and the nine-argument calls to mnparm; 
these will be replaced by methods which are more 
readable and which assigns one easily understood pur- 
pose to each method called. Still, when the user con- 
structs a minimization problem and invokes problem 
methods, she is logically employing capabilities which 
encompass the same set as was available in Minuit. 

2.2. Modern 0-0 Approach 

To make best use of the object oriented abilities pro- 
vided by C++, it is not enough merely to ensure that 
a minimization problem can be used as an indepen- 
dant entity. We must use the tools at our disposal to 
make the setup and control of a minimization problem 
as clear and flexible as possible. The focus is on user 
code readability, and on avoiding traps where the user 
can do something which looks sensible but may have 
disasterous (or worse, subtly incorrect) consequences. 

This means isolating conceptually distinct areas of 
control, and providing ways of excercising control of 
one aspect of execution at a time. Thus the user will 
be able to interact with termination conditions associ- 
ated with a problem, and separately with the domain 
restricting ranges of parameters, and with the selec- 
tion of algorithms. 

In each of these areas, the user controls behavior by 
interacting with specialized versions of objects. The 
minimization problem then interacts with these ob- 
jects via by their base class interfaces. An example is 
in order: 

To control how parameters are limited in range, the 
Problem will own an instance of a Domain. Domain 
methods takes care of such necessities as translat- 
ing Points and Gradients between internal unre- 
stricted Cartesian coordinates used by the algorithm, 



and external parameters known to the function. But 
Domain by itself is merely a base interface class; the 
actual Domain attached to the Problem would (by 
default) be a RectilinearDomain, which provides 
the capabilities present in Minuit: Restricting the 
upper and/or lower limits on each parameter indi- 
vidually. RectilinearDomain inherits from Domain. 
The user who desires to alter these limits would ob- 
tain a pointer to the Domain, and invoke methods of 
RectilinearDomain such as setUpperLimit(n,x). 

Now suppose another user has a problem which 
should be restricted to a region delimited by arbi- 
trary planes in parameter space. This user would 
provide a different sort of object inheriting from 
Domain-say LinearConstraintsRegion. And then 
she might call methods of that class, such as 
f orceLessThan(coef f icients , maximum). The al- 
gorithm does not care which type of Domain is in place. 

In providing the user interface, it is tempting to 
parallel the control made available to Minuit. This 
is good only insofar as there aren't opportunities to 
improve on the semantics provided by the Minuit sub- 
routines. We are finding that there is a tendency to 
rely too heavily on doing what Minuit does, and we 
need to be careful to look for opportunities to provide 
interfaces which would be clearer to people who are 
not steeped in Minuit usage. To paraphrase Strous- 
trup, this package should be "as close to Minuit as 
possible, but no closer." 

2.3. Extensibility and Maintainability 

The design of the package must be such that as 
new algorithms and anaylsis methods are developed, 
or as new types of termination conditions or domains 
are required, they can be added cither to the package 
itself, or to one's local version of the package. 

We cannot insist that the work associated with such 
an enhancement be small, because in principle coding 
some new algorithm might inherently involve a lot of 
effort. What we can, and do, insist on-and this drives 
the entire package design-is that the additional work 
imposed by being part of this minimizaztion package 
is a very small fraction of the typical work needed 
to create the new algorithm or domain itself. This 
"additional work" includes 

• Understanding all the steps one needs to do. 

• Following the logic of existing package code if 
necessary. 

• Discovering precisely where modifications will 
be needed, and what the nature of any new 
classes must be. 

• Coding any C++ boilerplate needed to support 
the enhancement. 
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These are the tasks which represent a barrier to 
putting an enhancement into any of the various C++ 
Minuit translations, and we must ensure that this bar- 
rier is small. 

Moreover, we must see to it that the enhancer, who 
may well be an expert in algorithm coding, need not 
also be an expert in CH — h 

The way to accomplish these goals is to carefully de- 
sign the system such that any two concepts that need 
not be logically intertwined, are expressed as distinct 
classes which interact as little as possible. The over- 
all package must be split into distinct subsystems, and 
dependencies carefully controlled. If this is done prop- 
erly, then the enhancer need only be concerned about 
the small corner of the package this enhancement will 
involve. Thus all the code to be examined in creating 
a new algorithm class would be in the Algorithm base 
class, and all the boilerplate involved would be found 
in classes in the Algorithm subsystem. 

The same philosophy that leads to ease of enhance- 
ment without undue tracing through an entanglement 
of code, will also greatly reduce the burden of mainte- 
nance. Over the long term for a non-commercial pack- 
age, one has to assume that any maintainer might well 
lose familiarity with the internals of the system. So 
it is crucial that proper coding idioms be employed, 
to avoid setting subtle traps. And good separation of 
functionality and control of dependencies are critical, 
so that when changes need to be introduced, they will 
be localized and not have tendrils of effect throughout 
the package. 

Also, each class should have self-contained (and 
easy-to-automate) unit tests; each subsystem should 
have integration tests only involving it and any sub- 
systems it depends on; and a good suite of regression 
integration tests should be provided to help catch any 
errors introduced. 

Having set a goal of easy enhancement, we must 
recognize that there are different sorts of enhance- 
ments which will normally be performed by different 
levels of developers. A user might well want to create 
some new form of Termination condition; this must be 
very straightforward. More rarely, a more experienced 
coder might want to derive a new type of Domain (for 
example, a RectilinearDomainbut replacing the arc- 
sin mapping function with some sort of sigmoid) . Still 
more rarely, adding a fundamentally new algorithm is 
the sort of ehancement which might be assisted by the 
principal package maintainers. 

2.4. Realm of Efficient Operation 

In the "low-ceremony" tight design iteration pro- 
cess so often sucessfully used in High Energy Physics 
code development, certain fundamental design consid- 
erations are often overlooked. Two such considera- 
tions are the required levels of agility and efficiency 



under various circumstances. In the course of design- 
ing this package, there will be opportunities for trade- 
offs among areas such as coding style, levels of agility 
when faced with minor changes in needs, and perfor- 
mance efficiency. An up-front grasp of the goals in 
these area will allow the developer to make intelligent 
choices. 

We have discussed above the agility considerations, 
in terms of extensibility and maintainability goals. As 
to efficiency, the typical first reaction is to say "of 
course this should be as efficient as possible," but that 
is an inappropriate goal for this package. Taken to 
the extreme, a total focus on efficiency might dictate 
unmaintainable coding tricks, avoidance of sound ac- 
cepted C++ techniques, and ultimately abandoning 
the object-oriented paradigm. Some aspects of per- 
formance efficiency are critical, but the design goals 
should permit other forms of efficiency to be sacri- 
ficed in favor of better modularity, semantic clarity, 
or other desirable features. 

The HEP minimization problem has a natural set 
of performance goals, and these induce an efficiency 
philosophy which is implied in Minuit, and which we 
state implicitly for our package: It is assumed that the 
work involved in an invocation of the function being 
minimized is very large compared to the overheads of 
bookkeeping, argument passing, and transformations 
of parameters. Thus tradeoffs which involve attaining 
beneficial properties at the cost of incuring extra work 
in these bookkeeping areas are considered positive. 

Furthermore, it is also assumed that the number N 
of parameters for tractable minimization problems of 
the nature we are considering will not be too large. 
By this, we mean that even in an algorithm which 
requires operations (such as inversion) involving N x 
N matrices, the time spent for such operations does 
not dominate the time needed to evaluate the fuction 
in forming those matrices. 

2.4.1. Performance-based limitations 

This minimization package will perform well on 
problems in which the dominant time cost is that of 
evaluating the function. Because of the tradeoffs be- 
tween some forms of efficiency and other desirable fea- 
tures, this package may not perform efficiently for cer- 
tain other classes of problems. It is tempting to say 
that such problems-which involve inexpensive func- 
tion calls-are so low-cost that nobody should care 
about performance, so that this minimization pack- 
age is suitable for all uses. We should realize that the 
above rationalization is a bit facile; there are actually 
at least four cases in which efficiency considerations 
may become important: 

1. Each call to evaluate the function is expensive. 
This is the case in most HEP fitting applica- 
tions, and is the case which our package will 
deal with well. 
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2. Some problems are potentially expensive not be- 
cause each function call is costly, but because 
there are a large numbers of parameters, such 
that matrix operations or even variable trans- 
formations begin to become dominant. 

3. When the number of parameters is huge, the al- 
gorithm may require a huge number of function 
calls. If function calls are inexpensive relative 
to the number of parameters, then bookkeeping 
overhead can become significant. The minimiza- 
tion problems appearing in Lattice QCD to find 
fcrmion propagators are of this nature. 

4. The overall scientific problem being solved may 
involve solving large numbers of easy minimiza- 
tion problems. Thus, while no single mini- 
mization is costly, performance on each prob- 
lem might remain a critical consideration. In 
that case, problem initialization costs can be- 
come important. 

The efficiency requirement laid on this minimization 
package, or for that matter on Minuit, is that it is 
appropriate for efficient solution of problems in the 
first of the above categories. This has been found to 
meet the fitting and other minimization needs of most 
HEP applications other than Lattice QCD. 

3. C++ CONSIDERATIONS 

The immediate preferences of potential HEP users 
can come into tension with the desired use of classi- 
cal C++ coding idioms accepted by top practition- 
ers. Concepts which are legacies from the Fortran 
days lead physicsts to become comfortable with cod- 
ing techniques which are today recognized as poor use 
of C++. In such cases, it is better to use the accepted 
modern idiom, rather than to deliver inferior-but tem- 
porarily more familiar-interfaces. 

Thus for example, it would be unwise to shun the 
use of auto_ptr when that is the appropriate way to 
convey the passing of responsibility for an object. The 
assumption is made that physicists who may at first 
be uncomfortable due to unfamiliarity with this idiom 
will quickly pick up on it. And the benefits in using 
concepts which have been battle-tested by the world 
of developers, and which match the understandings of 
skilled programmers, are considerable. 

Few of the decisions discussed in this section were 
black and white, and some may change in the course 
of coordinating with the CERN effort, but after some 
consideration, the following principles were adopted: 

3.1. Function or Functor? 

How does the user supply the function to be mini- 
mized? The naive mechanism is that the user passes to 



the Problem a global-scope function of some specified 
signature (for example, taking a vector of coordinates 
and returning a value). In fact, this notion is so ob- 
vious to the physicist coming from Fortran, that we 
must support it in some manner. 

But there are considerable advantages to being able 
to supply a functor (a instance of a class that has 
an operator () so that it looks like it can be called 
as a function) instead. One advantage to suppying a 
functor is that unlike the global function, an instance 
of a functor may have internal state, and the class may 
provide methods to influence the function behavior. 
(For example, one may wish to sum errors over fewer 
data points early in a minimization problem, and more 
later.) 

This natural concept in C++ replaces the awkward 
nature of fcn in Minuit, which contains six argu- 
ments. Only two arguments arc fundamental to the 
notion of a function to be minimized: The vector XVAL 
of coordinates, and the result fval. By allowing for a 
functor class, we obviate the need for IFLAG and fu- 
til; and by separating the gradient method we elimi- 
nate the GRAD argument. 

3.2. Object Ownerhip and Responsibility 

The package has several situations in which behav- 
ior is defined by hooking into user code. Two examples 
are the functor representing the function to be min- 
imized, and a Domain object implementing limits on 
cooordinates. 

The pattern of allowing a user to control behav- 
ior, by supplying a class which overrides one or more 
"hook" methods, resonates well with physicist coders. 
Were we to say that the user constructs a Problem 
supplying a reference or pointer to an instance of 
some class derived from Function, the HEP commu- 
nity would not complain. And if we further warned 
the user not to allow this function to go out of scope 
while the Problem still needs it, most users would find 
that an obvious caution. 

However, the consequence of violating that stricture 
are dire: When the Problem calls (by pointer) the out- 
of-scope method, confusion will reign, with no sensible 
diagnostic to point out why. Good library develop- 
ers protect against this by copying the vulnerable ob- 
ject. The Problem, then, will own the Function and 
Domain, and not risk having those objects "pulled out 
from under it." This notion is expressed by the user 
passing an auto_ptr to a new object (on the heap); 
the Problem assumes responsibility for deleting that 
object when it no longer needs it. 

Having made that decision, we must provide a way 
for the user to invoke controlling methods on the in- 
stance of the functor owned by the Problem. The 
original object that the user supplied to the Problem 
won't do, since the Problem will be using a copy of it; 
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in fact, if the correct mantra was used to pass owner- 
ship to the Problem, the user code should no longer be 
able to access the original object. Instead, the correct 
recipe is: 

• The user obtains a pointer to the base class (in 
this example, Function) by calling a method of 
Problem (in this case, getFunctionO ). 

• This pointer is dynamic cast into the class the 
user needs to control. The user can then invoke 
any control methods applicable for that class. 

• The pointer is now allowed to go out of scope, 
without the user calling delete on it. 

The suggested syntax, which automatically obeys 
this recipe, involves using the returned pointer as a 
temprary variable which never is valid outside a single 
statement. The syntax can look like: 

dynamic_cast<RectilinearDomain> 
myProblem . getDomain ( ) -> 

setUpperLimit (paramNumber , 35.1); 

Because this mantra may not be immediately famil- 
iar to our users, it is important that the package stick 
to the same rules {never use delete on a pointer which 
Problem has supplied) for every case of object access. 

3.3. Use of Templates 

The powerful template facility in C++ would allow 
clever ways to improve the user interface and/or im- 
plementation of the Minimization package. To give 
one example, methods giving a choice of supplying a 
user function or functor to act as the minimization 
target could be unified by expressing Problem as a 
template, taking the function class as a template pa- 
rameter. 

The use of templates has several adverse conse- 
quences which we perfer to avoid where practical: It 
makes it a bit tougher for a user to comprehend a 
header file, it can make maintenance more difficult, it 
makes compilation error messages much less readable, 
it introduces quirky linking issues, and it risks harm- 
ing portability on certain weak compilers. There are 
valid answers to each of these objections; still, absent 
compelling benefits, the package design avoids the use 
of templates. 

On the other hand, existing templated classes in the 
standard library are used freely. 

3.4. Sophisticated Patterns 

Our philosophy concerning clever and subtle pat- 
terns to which convey minor benefits is that it is some- 
times possible to be too clever. 



For example, the design of the Function base class 
(discussed in section I4.5JI makes it possible to sup- 
ply a gradient () method but forget to override 
gradientAvailable () . That is a bit of a trap-the al- 
gorithm would ignore the user-supplied method when 
it needed a gradient. (The same trap is present in 
Minuit, if the user forgets to call setgradient). 

We could finesse this by using a variant on the vis- 
itor pattern: When the algorithm needs a gradient, 
it requests it from the Function object but the sig- 
nature of the gradient () method also supplies the 
address of the algorithm's finite difference gradient- 
computing method. The base class gradient () in- 
vokes this method; if the user's functor class overrides 
gradient () that routine replaces the finite difference 
method behavior. This pattern incurs some efficiency 
loss, but since that is merely a matter of an extra ar- 
gument passed around, and an extra subroutine call, 
that cost would (by the definition in section be 
acceptable. However, the pattern looks complicated 
and mysterious; it might make maintenance more dif- 
ficult and it might worry potential users who haven't 
put in the time to understand it. Since the gain is 
relatively slight, we have come down on the side of 
the simpler gradientAvaliable () solution. 

3.5. When to Introduce a Class 

In many cases, there may be multiple concepts for 
which the natural expression in bits and bytes will 
look like identical data structures. For example, both 
the set of coordinates identifying a point, and the set 
of values representing the components of the gradient 
of a function, are underneath indexed collections of 
doubles. The question is, should the design introduce 
distinct classes to represent the distinct concepts, or 
should it use a vector of doubles for both? 

Good C++ design takes the view that if two con- 
cepts are distinct, they should be represented by two 
distinct classes. The idea is that you can't be sure in 
advance that you will never alter the way you work 
with one of the concepts, and if they are represented 
by distinct classes, making such a change will be much 
less of a maintenance headache. Introducing a distinct 
class to represent each distinct concept also provides 
some measure of type safety, in that you can't acci- 
dently use one concept when you mean the other. And 
naming each concept leads to superior code readabil- 
ity. In a package that emphasizes extensibility, these 
three advantages are significant. 

The disadvantage in introducing such classes is lim- 
ited to the need to write some boilerplate code writing 
to provide their headers and near-trivial implementa- 
tions. Therefore, especially concerning minimization 
package internals, we tend to introduce distinct classes 
for distinct concepts, particularly in the area of geo- 
metric concepts (see section such as Point and 
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Gradient. 

3.6. Namespace 

The minimization package must be a good CH — h 
citizen. By that, we mean it must not step on poten- 
tial user symbols; we place everthing into a namespace 
to guard against this. Other items we avoid are the 
use, in headers, of macro definitions (which may clash 
with user defines) and of using statements (which de- 
feat the purpose of the namespace protection if they 
appear in an included header). 

Namespace use has been approved for the CLHEP 
library, which has severe portability requirements, so 
we are not concerned on that issue for the Minimiza- 
tion package. 

4. LOGICAL DESIGN 

The package is divided into several subsystems. A 
subsystem is defined as some group of classes and re- 
sponsibilities, such that each subsystem depends on a 
minimal number of other subsystems, and such that 
these dependencies can be expressed as cleanly as pos- 
sible. The first step in logical design was to identify 
the concepts present in Minuit. It is no coincidence 
that each subsystem coresponds to one major concept 
in the minimization realm. 

The benefit of a good separation into subsystems 
comes during development of various classes, and 
later during enhancement implementation, because 
the coder can have in mind a smaller "overall pic- 
ture" when deciding how to do things. Good isola- 
tion of subsystems makes it possible to develop the 
more detailed package design one part at a time, with- 
out constantly having to consider the ramifications of 
each decision on every other part of the design. Fi- 
nally, the up-front thought about subsystem compo- 
nents has yielded immediate benefits in the form of 
solidifying the collection of concepts involved in the 
minimization package. 

In principle a "subsystem" need not be tied to a 
group of classes. However, each identified subsystem 
in the Minimization package is characterised by a key 
class embodying the interface of that subsystem to the 
user and/or to the other subsystems. This section will 
outline the responsibilities and dependancies of each 
subsystem, and discuss associated design issues. 

4.1. Problem 

The Problem subsystem has the responsibility for 
the user interface to a minimization process. It con- 
tains the Problem class, which takes ownership of 
Algorithm, Domain, and Termination objects, and 
contains the ProblemState. 



Minimizing involves the Problem repeatedly 
requesting steps from the currently associated 
Algorithm. After each step, it determines whether 
the user-supplied termination condition is satisfied, 
or whether the algorithm itself has declared that it 
can't profitably proceed further. If termination is 
reached, control returns to the user code, which may 
change the Algorithm, the Domain (for example, 
releasing some parameters and fixing others), and/or 
the Termination conditions, and again invoke the 
problem's minimize () method. 

4.2. ProblemState 

ProblemState is a structure containing information 
about the state of solution which is not peculiar to any 
one algorithm or domain. For example, the concept 
of the current best guess is inherent in the nature of 
minimization; it is applicable whehter the algorithm 
producing it was migrad or simplex. 

The user indirectly interacts with ProblemState, 
via methods of Problem, when she needs to inspect 
this information. Subsystems of the minimization 
package interact with ProblemState more directly. 
For example, Termination conditions inspect its data 
to decide whether to terminate, and the Algorithm 
subsystem is dependant upon ProblemState, reading 
and altering its data. 

There is danger that ProblemState can act as a 
catch-all for data that violates reasonable encapsula- 
tion goals, effectively replicating-with all its flaws-the 
notion of a big global common area. There is some art 
in restricting the contents to those items genuinely in- 
herent in the minimization concept, and keeping those 
items which are associated with an algorithm in the 
specific Algorithm classes. 

4.3. Algorithm 

The Algorithm base class provides interface be- 
tween the Problem and subclasses implementing spe- 
cific minimization algorithms. This base class also 
standardizes ways for its derived classes to access 
the function and domain objects. For example, the 
mantra for obtaining a function gradient involves find- 
ing out whether the Function object can provide it 
analytically, and if not, utilizing the algorithm's own 
finite difference methodology; this mantra is encapsu- 
lated in Algorithm. 

Any given algorithm class has an iterate () 
method, which "takes a step," improving the state 
of solution. It also decides whether to declare that 
this algorithm is finished in the sense that no further 
meaningful improvement is forseen. Between steps, 
the Problem applies user-supplied Termination con- 
ditions which may declare victory well before the al- 
gorithm declares exhaustion. 
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This subsystem depends on the Function and Do- 
main subsystems: Algorithms, of course, repeatedly 
requests values of the function (and if available its gra- 
dient and second derivatives), and utilize the Domain 
to map its internal coordinates into external parame- 
ters to supply to those function calls. 

4.4. Analysis 

This subsystem has the responsibility for the vari- 
ous solution analysis tools such as MINOS, hesse, and 
CONTOUR. Such tools have roughly the same needs 
and dependencies as algorithms, but a class derived 
from Analysis can in addition also depend on Algo- 
rithms which it needs to call. 

4.5. Function 

The Function subsystem has the responsibility for 
providing function values and, if available, analytic 
gradient and second derivatives. The primary class is 
the abstract interface Function. 

Commonly, users will have an ordinary function 
(taking a constant refernce to a Point or to a vec- 
tor of doubles, and returning a double) to mini- 
mize. Such users can make use of the free method 
UserFunctionO , to supply this function when con- 
structing the Problem, as in: 

double f (const vector<double> v) { 

assert (v.size()=nargs; 

// ... do work to return a value } 
Problem myprob ( UserFunction (nargs, f) ); 

An alternative signature would take both the func- 
tion and a method to compute the gradient, if direct 
gradient computation is available. The user can also 
optionally supply global methods to compute second 
derivatives. 

UserFunctionO constructs a Function object on 
the heap, and returns an auto_ptr to it; in the example 
code, this is immediately passed to the constructor of 
the Problem. 

Alternatively, a user can inherit from Function to 
form his own "functor" class, and supply an instance 
of that when constructing a Problem. In that case the 
functor class must override the method which returns 
the function value at a point. It may also override the 
gradient () method, and if it does, it should override 
gradient Available () to return true-this replaces 
Minuit's SETGRADIENT command, and more impor- 
tantly, obviates the need for the user function to be 
passed an iflag argument to tell it what do do. Sim- 
ilarly, the functor class may override the hessianO 
and hessianAvailableO methods. 

The functor is to be created on the heap and an 
auto_ptr supplied to the Problem so that there is no 
danger of the user getting mysterious errors due to 



the functor going out of scope while the Problem is 
depending on it. The user can later recover a pointer 
to this function object and thus invoke its methods: 

class MyFunct : public Function { 
MyFunctO : Function (nargs) {> 
double operator () (const Pointfe p) ; 
changeStuf f (int c) ; 
...}; 

Problem myprob ( auto_ptr<Function> 

(new MyFunct) ) ; 

(dynamic_cast<MyFunct*> 

(myprob . getFunctionO ) ) ->changeStuf f (3) ; 

The Function subsystem depends only on the Geo- 
metric Concepts subsystem. 

4.6. Domain 

The Domain subsystem has the responsibility for 
providing mappings between the internal coordinates 
that an algorithm works with, and the external pa- 
rameters that a function deals with. This solidifies 
the decoupling, already present in Minuit, between 
the algorithm and any restrictions on the parameter 
values. That is, it would be too difficult to invent 
an algorithm that could deal with any arbitrary sort 
of variable restrictions; instead, the algorithms them- 
selves work with clean, unrestricted Cartesian coor- 
dinates, and all the complexity involving restrictions 
is separated off into the Domain classes. The Domain 
base class provides the interface for algorithms and 
other parts of the package to transform variables. 

There is, of course, the complication that geo- 
metric objects of different kinds transform differ- 
ently under the mappings provided by a Domain. 
Thus specific Domain derived classes provide meth- 
ods to map various Geometric Concepts: Points, 
Gradients, Hessians, CharacteristicScales, (er- 
ror) Correlations, and whatever else algorithms and 
analyses may need. The base Domain class supplies 
these methods in terms of virtual functions which sup- 
ply the map's value and derivatives. 

Domain encapsulates the Minuit concepts of param- 
eter limits and of fixing/releasing parameter values. 
Half the interface of Minuit is devoted to manipulat- 
ing the way parameters can vary. Most of this control 
belongs in the Domain subsystem. 

The exemplar of a Domain (and the one as- 
sociated with a Problem by default) is the 
RectilinearDomain, which provides the mapping 
functions and capabilities present in Minuit. A 
user could fairly easily create a class inheriting from 
RectilinearDomain in order to modify the mapping 
functions used. 

RectilinearDomain has the property that its indi- 
vidual components map in a separable way, that is, the 
map of each internal component depends on only one 
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variable external parameter. Algorithms can query a 
Domain about this property. For example, when MI- 
GRAD utilizes diagonal second derivatives to avoid the 
need for computing the full Hessian, it relies on this 
separablity property; and in more complex Domains, 
additional work may be needed. 

Unlike functors derived from Function, which need 
only supply the fundamental value-suppying method 
(and may optionally supply gradient etc.), each 
Domain subclass is required to supply all the Geo- 
metric Concepts mapping methods. While typical 
users are expected to create functors deriving from 
Function, we can assume that those who embark on 
defining new types of Domains are somehwhat more 
expert. 

The Domain subsystem depends only on the Geo- 
metric Concepts subsystem. 

4.7. Termination 

The Termination subsystem has the responsibility 
for conditions conditions which the problem can ap- 
ply, to determine whether to terminate the minimiza- 
tion iteration and return control to the user. The 
Termination base class also defines an interface for 
potential user-created termination conditions. 

The subsystem contains Termination classes corre- 
sponding to each of the criteria applicable in Minuit, 
plus a time-based criterion. Time-based termination 
is often preferable to a count of function calls, but has 
a potential disadvantage with respect to portability. 
However, the standard library does provide for tim- 
ing at the one-second granulaty level, and almost all 
systems are compliant in this respect. 

Termination also comes with methods to build 
"compound" Termination objects as by logically com- 
bining (and, or) more basic Termination objects. 
Such a compound criterion could, without too much 
difficulty, be coded by each user as a class deriving 
from Termination. But the desire to apply a group 
of criteria, terminating (say) if either the accuracy 
criterion is met, or the number of function calls is 
excessive, will be a very common case. So it was de- 
cided to make life easy for such users by supporting 
these combinations. We supply the logical combiners 
AND and OR, as this will satisfy the vast majority of 
applications. 

The Termination subsystem depends on Problem- 
State. 

4.8. Geometric Concepts 

The minimization process deals with a number of 
geometric concepts, which are logically distinct and 
not interchangeable. Most of these behave like a vec- 
tor of doubles. For example, a Point in exterior co- 
ordinate space is not interchangeable with a Gradient 



of the function at some point, even though they both 
have the same number of components. And neither is 
the same as an "InteriorPoint" which is a set of coor- 
dinates in the Cartesian space in which the algorithm 
is working. 

Although the package code utilizes these Geomet- 
ric Concept classes, there is good reason to provide 
user interfaces for common operations which deal with 
the familiar vector of doubles. For example, the 
UserFunctionO method can accept a function of a 
std: : vector where a Point is logically called for: 

double f (const std: : vector<double> params) ; 
Problem myprob ( UserFunction (nargs, f) ); 

The exterior concepts identified are Point, 
Gradient, SecondDerivatives, Hessian, 

CharacteristicScale, and Correlations. There 
are also classes corresponding to each of these, 
representing internal-coordinate concepts. 

The Geometric Concepts subsystem contains the 
collection of such classes. It depends on no other sub- 
system. 

5. IMMEDIATE ENHANCEMENTS 

The initial release of the minimization package is, 
by definition, to include all Minuit functionality. Of 
course, the object nature of a minimization problem 
will allow modes of usage which would be awkward 
with the Fortran Minuit, but basically the capabilities 
will at that point be those of Minuit. However, certain 
extensions will be in the initial release. These appear 
in situations where the nature of a potential extension 
is obvious, and the implementation is straightforward. 
If the extension is clear in definition, and we have 
a firm idea of how it should by implemented, then 
there is no reason to delay that capability unitl a later 
release. 

In the Domain subsystem, the RectilinearDomain 
class will immediately support half-open intervals for 
parameter limits (that is, having only an upper or 
lower limit for a paramcnter). It will also be easy to 
substitute for the arcsin mapping functions. 

In the Function subsystem, the package will allow 
supplying second derivatives (either diagonal or full 
matrix) along with the gradient. 

In the Termination subsystem, several new basic 
choices will be provided, including a time-based ter- 
mination, and arbitrary logical combinations of ter- 
mination conditions will be supported. 

6. STATUS 

A preliminary partial implementation of this pack- 
age has been done, to obtain familiarity with the Mi- 
nuit algorithms and concepts, and to get a feel for 
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the design issues. (A spin-off of this work is a set 
of heavily-commented Minuit Fortran "source" code, 
and some mathematical documentation of the Minuit 
algorithms.) 

The package design is completed (though not set 
in stone) and most interfaces have been defined and 
headers coded. Re-implementation of the classes, 
based on the actual design, is in progress. 

The CERN effort (as discussed with F. James) is at 
the point where the minimization algorithms (but not 
all of the analysis algorithms) have first-pass imple- 
mentions, again in a familiarization phase. Since the 
two efforts are at comparable stages, the prospects for 
coordination seem reasonable. 
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